Hi @vercellone

Thank you very much for this contribution!

Please allow me a few days to think about this, as it's the first use of an API which is new with version 3 🎉
I don't know yet how to handle the error scenario on a server that does not support v3 yet.

Some question to you, though:
Is it a conscious decision not to have any parameter support the pipeline? Or list input for that matter.
Also, why not allow for project keys to be passed to the function?

I did avoid less objective features pending feedback. But, I can implement those.

1. How should -Sort be handled for Name list and pipeline scenarios considering that some sort properties may not be included in the responses?

Evidently, the endpoint is unchanged from v2 to v3. 2, 3, and latest all work. So, the currently coded Uri should be fine as-is:
$searchURi = "$server/rest/api/latest/filter/search"

I tested this api on

• Jira v7.13.5 (not cloud) 👎
• Jira 4cb60bea (cloud) 👍

it's not part of the Jira Server 8 Api doc.

The error return when the API does not exist was

Invoke-JiraMethod : Server responsed with NotFound

this might be relevant to refactor with a "Not supported by server" error once the module has better responses